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TITLE 

A method for organizing financial instruments in a CSD-system. 
TECHNICAL FIELD 

The present application relates to a method for use in a so-called Central Securities 
Depository, commonly abbreviated as CSD, by means of which method financial 
instruments can be organized in the CSD-system. The invention also discloses a 
computerized system for carrying out the method. 

BACKGROUND 

Traditionally, centralized institutions have been used mainly for storing gold which 
belongs to different nations in the same location. When transferring assets from one 
nation to another, all that needs to be done is to simply transfer gold from the "pile" 
which belongs to the paying nation to the "pile" which belongs to the nation that is to 
receive the payment. The principles of centralized institutions greatly facilitates the 
processing of payments, and for this reason, there is an interest in using such 
centralized solutions for commodities other than gold, in principle for any kind of 
commodity or instrument that can be imagined in the financial market, e.g., bonds, 
shares, etc. 

In such an "expanded" centralized system there would be a plethora of instruments. 
The gathering of all instruments in one place (physical or virtual) is advantageous for 
those using the system, e.g., issuers, investors, and the operator of the system. Such a 
system is referred to as a Centralized Securities Depository, abbreviated as CSD. 

Each kind of financial instrument in such a system would be defined by attributes, 
which are specific for each individual instrument. According to contemporary 
solutions and systems, the attributes for each individual instrument comprised in a 
system are "hard coded". Due to, inter alia, the vast amount of instruments which the 
system needs to be able to handle, this "hard coding" makes the system difficult and 
cumbersome to handle, for example, due to the fact that new financial instruments 
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can appear in existing markets, or when it is desired to adapt the system to new 
markets, or exchange information between the markets. 

SUMMARY 

5 There is thus a need for a method to add new instruments in an easy manner to an 
existing CSD-type system. The method should also facilitate making amendments to 
existing instruments in the system. 

This need is met by the present method for organizing financial instruments in a 
10 CSD-system where the instruments can be traded. Attributes are assigned to the 
instruments which define the instruments. The instruments are organized in a 
hierarchic multi-level structure as follows: 

• a link is created between a first instrument on a first level in the hierarchy and 
instruments on a second, lower level in the hierarchy, 
15 •the link between the instruments on the first and second levels of the hierarchy is 
defined by the fact that all of the attributes which are comprised in the 
instruments on the second level are also comprised in the instrument on the first 
level to which the instruments on the second level is linked. 

20 Preferably, each instrument is only linked to one other instrument on a level above it. 
Any amendment to an attribute in an instrument causes the same amendment in the 
same attribute of those instruments which are linked to the amended instruments and 
which are on lower levels in the hierarchy than the amended instrument. In this way, 
amendments to existing instruments are greatly facilitated, since amendments need 

25 only be made on the highest level common to the instruments which are to be 
amended, and the amendment will then "trickle down" to the instruments in question. 

The technology greatly facilitates the adding of new instruments to the system. When 
there is a need or desire to add a new instrument to the system, an existing instrument 
30 in the CSD-system is found which has at least all of the attributes of the instrument 
to be added. The new instrument is then placed on a level in the hierarchy of the 
system which is below said existing instrument, and a link is created between the 
instrument to be added and the existing instrument. 



3 



A computerized CSD-system is described, which comprises a register of instruments. 
The register is organized along the principles described above. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig 1 shows one of the principles behind the technology, 

Fig 2 shows a method, 

Fig 3 shows an example of the method, and 

Figs 4 and 5 show flowcharts. 

10 

DETAILED DESCRIPTION 

In a CSD-system where various financial instruments are traded, the instruments are 
defined by attributes. Examples of attributes include the identity of the issuer of the 
instrument in question, the ISIN code, or some other code which identifies the 
1 5 instrument, e.g., CUSIP, the date of issue of the security, the interest rate, etc. 

In addition to the objectives described above, additional desirable objectives for 
instruments in the register of a CSD-like system include: 
- re-using different attributes between different instruments, and 
20 - deriving one instrument from another instrument 

A multi-level hierarchical system is provided for organizing a register of financial 
instruments in a CSD-system. The number of levels preferably is not restricted by an 
upper limit. 

25 

With reference to Fig 1 , one of the principles of a multi-level hierarchy will now be 
explained. In Fig. 1, a group of instruments is shown arranged in a multi-level 
hierarchy. Instruments on a higher level (AB) can have links to several instruments 
on the lower levels (ABBB, ABCC). Each instrument preferably only has one link to 
30 the level above its own. 

The instruments (AB) at the top level of the hierarchy are suitably not instruments 
which can be traded as such, but are rather generic "templates" for the instruments on 
the lower levels (ABBB, ABCC; ABBB 123, ABCC456) that are "real" instruments 
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that can be traded, e.g., government bonds or mortgage-backed securities and shares. 
A template in a system organized can either serve as a template on the next level, or 
as a template for an instrument on the next level. Although Fig. 1 only shows one 
group of instruments, the system can comprise a virtually unlimited number of such 
5 groups. 

As can be seen from the group shown in Fig. 1, one of the principles behind the 
technology is that any instrument on any level of the system "inherits" all of the 
attributes of the instrument to which it is linked on the level immediately above it. 

1 0 This principle could in fact be said to essentially be the definition of the links 
between the instruments. Due to this linkage principle, when there is a need or a 
desire for making amendments to one or more instruments, all that needs to be done 
is to locate, within the hierarchy, the attribute which is to be changed. When the 
attribute is amended, that particular amendment will "trickle down" to the linked 

1 5 instruments. 

When organizing the group in Fig. 1, the following steps could be used: 

- Look at the real instruments (ABBB123, ABBB862, ABBB293; ABCC456, 
ABCC578, ABCC394) which are to be comprised in the register of the CSD- 

20 system. 

- Find a first set of common denominators (ABBB, ABCC) between the 
instruments. 

- Find a second set of common denominators (AB) between the first set of 
common denominators. 

25 - When all (or a preset number) of common denominators have been found, create 
a linked multi-level hierarchy according to the principles outlined above, with the 
instrument of the most basic common denominator at the highest level, and the 
real instruments at the lower levels. 

30 The steps described above are also outlined in the accompanying flowchart in Fig. 4. 

If, at a later stage, a new instrument needs to be added to the register, the following 
steps could be used: 
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• find an existing instrument in the CSD-system which has at least all of the 
attributes of the instrument which is to be added, 

• place the instrument which is to be added on a level in the hierarchy of the 
system which is below said existing instrument, 

5 • create a link between the instrument to be added and the existing instrument. 



These three steps are also outlined in the accompanying flowchart in Fig. 5. 

Fig. 2 shows another feature: inheriting of an attribute from a higher level to a lower 
10 level in the hierarchy is made either optional, mandatory, or excluded, i.e., 
prohibited. The "setting up" of which principle of inheritance that is to be used for 
each instrument and attribute within the system is suitably carried out by the operator 
of the system, in a manner which best suits each instrument and the system as a 
whole. 

15 

Naturally, all attributes can be made mandatory to inherit according to the principle 
of linkage explained previously, but the principle of Fig. 2 additionally enhances the 
ease of handling. As shown in Fig. 2, the template instrument at the highest level in 
the hierarchy comprises six attributes, three of which are optional (shown vertically 
20 striped), two of which are mandatory (shown horizontally striped) and one of which 
is excluded from inheritance (diagonal stripes). Thus, the attributes, which were 
mandatory for inheritance to the next level, appear in the instruments on the level 
below the highest level, and the attribute that was excluded from being inherited is 
also marked as excluded in the second level. 

25 

However, the attributes which were optional from the first level to the second may 
have different properties of inheritance when going from the second level to the third 
level in the hierarchy. This is indicated in Fig. 2 by virtue of the fact that in one of 
the instruments on the second level, one of the optional attributes is now marked as 
30 being excluded (diagonal stripes) when going to the next (third) level, and in the 
other instrument on the second level one of the optional attributes from the first level 
is marked as mandatory (horizontal stripes) for inheritance to the next level and one 
is marked as excluded (diagonal stripes). 
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In Fig. 3, an example applied to real instruments is shown: 

A group of instruments is organized in three levels. At the top level, there is an 
instrument template known as "Government bonds". The exact attributes of that 
template will not be enumerated here, as they should be well known to those working 
in the field. However, one attribute which Government Bonds have is that they 
generate an interest. In this particular case, interest can be generated in two ways: 
fixed or floating. Thus, at the top level, the template is provided with two attributes: 
one for fixed interest and one for floating interest. 

On the next level, there are two templates, one for each of the more specific cases of 
bonds, which have fixed interest rates, and bonds with floating interest rates. One of 
these templates will inherit the attribute "fixed interest" and the other template will 
inherit the attribute "floating rate". This is done by both of the interest attributes 
(fixed and floating) at the top level being designated as optional for the next level, 
i.e., the second level. Then, on the second level, in the template for fixed interest 
bonds the attribute for "floating interest" will be designated as excluded from the 
following levels. In a corresponding manner, the template for floating rate bonds will 
exclude the attribute "fixed interest" from the following levels. 

In addition to having a characteristic property, for example, fixed or floating interest, 
an attribute can also have a value. By way of example, in the case of the attribute 
being "interest," the value could be the interest rate. 

In order to make the system even more flexible and easy to organize, the inheriting 
of the value of an attribute from a higher level to a lower level can also be made 
mandatory or optional regardless of whether the attribute was optional or mandatory 
to inherit. How a value is to be inherited would be set by, for example, the operator 
of the system. 

If the inheritance of the attribute is mandatory and the inheritance of the value is 
optional, the instrument inherits a value as an example for the attribute (e.g., 
interest). A value needs to be set for the attribute in question since the attribute, i.e., 
the interest rate, is mandatory. The value could be either the inherited ("example") 
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value, or a new defined value. Naturally, other ways of setting a value could not be 
used, for example, using some kind of automated information retrieval system. If the 
inheritance of the interest attribute is optional, and that option is chosen, the interest 
needs to be set, which can suitably be done in the manner just described. 



